In typical role-based access control (“RBAC”) systems, access to an object within a computer system is provided to the members of groups termed “roles.” Subjects belonging to a given role have the same privileges to access various objects within the system. Individuals are then granted access to objects by being assigned membership in appropriate roles. RBAC is considered useful in many commercial environments because it allows access to the computer system to be conveniently organized along lines corresponding to the actual duties and responsibilities of individuals within organizations. For example, RBAC allows the access provided by roles to conform to a preexisting hierarchy. In a hospital environment, members of the “doctor” role will have broader access to protected objects than would members of “nurse”, who will in turn be given broader access than “health-care provider”. Various types of privilege can be conveniently organized as a function of role assignments. For example, “doctor” membership may allow the user the privilege to read from or write to a pharmacy record, while “pharmacist” may only allow the privilege of reading the record.
Security policies define the privileges that are assigned to various roles. In a conventional system, these security policies are written by security professionals. Often, they are written without any traceability to the applications that are required to respect them. Thus, an audit of those security policies requires that the auditor have all the skills required to both construct and audit the application policies, identify applications that give access to information resources, find an owner of those resources, examine the resource owners for a statement of policy, and then attempt to either test whether the policy is implemented or review the actual code. In other words, there is no standard method for authoring, auditing, and editing security policies that does not require an intimate knowledge of the implementations of those security policies.